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^ (57) Abstract: A data file is regarded as a digital package. A convenient interface is provided for scheduling pickup and delivery 
^ of the data file via one or more satellite communication links. The data file may represent various types of information, such as text, 
^ images, audio or video. A centralized .system receives the scheduling order and arranges for the data file to be auiomaiically picked 
^ up from one or more locations and delivered to one or more destinations. The delivery serv ice may include buffering the data file for 
a predetcranined time period to comply with the scheduled delivery time. The centralized system provides a scheduling confirmation 
O notice for the scheduled pickup and delivery, and also provides notice that the data file was actually delivered. The centralized system 
^ maintains an activity log useful for status inquiry and hilling. In short the cenu-alized system functions as a "dispatcher" for bits, 
^ within an infrasiruaure for receiving, tracking, deliivcring and billing based on bits. 
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PICKUP AND DELIVERY OF DATA FILES 

BACKGROUND OF THE INVENTION 
The present invention relates to a method and system for data file 
pickup and delivery, and, more particularly, is directed to a centralized system 
5 including a satellite link for delivering data files in accordance with instructions by 
a user through a screen-based interface. 

As the popularity of the Internet increases, there is a commensurate 
increase in the need to deliver content over large distances, bypassing clogged 
communication channels. Sometimes content must be delivered according to a 
specified schedule that may be one-time or recurring. This need is particularly 
critical for files which must be delivered in a real time or near real time sequence, 
such as audio and video files, and for files which must be delivered at the same time 
to a multiplicity of places. A similar situation exists for data streamed during 
delivery. 

There is also a need for an automated interface by which a user can 
schedule and manage transfer of data files, so that file transfer serx'ices can be 
provided in a highly cost-effective manner. 

SUMMARY OF THE INVENTION 
In accordance with an aspect of this invention, there are provided a 
method of and a system for transmitting a file using a satellite communications link 
in accordance with a scheduling order specifying pickup and delivery instructions 
for the file. 

According to a further aspect of the invention, the scheduling order is 
received from a user, the scheduling order also specifying at least one location and 
time for retrieval of the file. 

In accordance with anodier aspect of this invention, there is provided 
a user interface for scheduling a file transfer, comprising a terminal for displaying a 
data screen to the a user, the data screen including fields for specifying a file 
locafion, size, pickup time and deliver)' time, and means for sending information 
entered through the data screen to a central system. 
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^ In accordance with another aspect of this invention, there are 

provided a method and a system for receiving a file that has been transmitted using 
a satellite communications link in accordance with a scheduling order specifying 
pickup and delivery instructions for the file. 

According to a further aspect of the invention, this file is transmitted 

* 

5 by multicasting, and delivery availability according to the scheduling order is 
confirmed before the file is received. 

It is not intended that the invention be summarized here in its 
entirety. Rather, further features, aspects and advantages of the invention are set 
^ forth in or are apparent from the following description and drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 
Fig. 1 is a block diagram illustrating an environment in which the 
present invention is applied; 

Fig. 2 is a flowchart illustrating data file pickup and delivery 
' according to the present invention; 

Fig. 3 is a chart showing a screen for customer registration; and 
Fig. 4 is a chart showing a screen for scheduling data file pickup and 

delivery. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
The present technique regards a data file as a digital package, and 
provides a convenient interface for scheduling pickup and delivery of the data file 
via one or more satellite communication links. The data file may represent various 
types of information, such as text, images, audio or video. A centralized system 
receives the scheduling order and arranges for the data file to be automatically 
picked up from one or more locations and delivered to one or more destinations. 
The delivery service may include buffering the data file for a predetermined time 
period to comply with the scheduled delivery time. The centralized system provides 
a scheduling confirmation notice for the scheduled pickup and delivery, and also 
provides notice that the data file was actually delivered. The centralized system 
maintains an activity log useful for status inquiry and billing. In short, the 
centralized system functions as a "dispatcher" for bits, within an infrastructure for 
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receiving, tracking, delivering and billing based on bits. 

The centralized system provides comprehensive management of 
communication channel capacity, particularly in the space segment. Multiple 
satellites may provide capacity on an on-going basis, with capacity available on 
additional satellites during peak demand. The centralized system also efficiently 
manages capacity on inler-satellite links, if any. 

The present technique also provides a user with an easy to use 
screen-based interface for scheduling data file pickup and delivery without the 
burden of managing communications capacity. The user interface also allows the 
user to track the progress of the data file from its source(s) to its desiination(s). 

Referring now to the drawings, and in particular to Fig. 1 , there is 
illustrated an environment in which the present invention is applied. Fig. 1 shows 
communication satellites 10, II, inter-satellite link 14, satellite links 15, 16, 17, 18, 
19, terrestrial network 20, earth stations 30, 31, 35A, 35B, 35C, controllers 40, 45, 
J 5 data buses 42, 47, transmitter 50, receiver 55, data storage units 60. 65, gateway 70, 
client 75, sending customer terminal 80, service provider premises 90 and customer 
premises 92, 95. 

Generally, tenrestrial links are assumed to operate in a duplex 
2Q handshaking manner. Satellite links typically operate in simplex mode although a 
return link is sometimes configured via a terrestrial or other satellite link. 

Communications satellites 10 and 1 1 are preferably in geostationary 
orbit. Other orbits may be used, and those of ordinary skill in the art will 
understand the additional communications overhead needed to communicate with 
satellites in other than geostationary orbit. Satellite 10 is adapted to receive 
information on uplink 15 from earth station 30 and to transmit the received 
information on downlink 16 covering earth station 35 A. This is referred to as a 
forward channel. In some embodiments, satellite 1 0 is also adapted to receive 
30 information from earth station 35A on a second uplink and to transmit the received 
information on a second downlink to earth station 30. This is referred to as a 
reverse channel. It will be appreciated that the actual communication channel may 
be the same for the first and second uplinks and downlinks, respectively, and can be 
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re-used. 

Satellite 1 1 is adapted to receive information on uplink 1 7 from earth 
station 3 1 and to transmit the received information on a downlink covering earth 
stations 35B, 35C. For clarity, the downlink from satellite 1 1 is depicted as 
downlinks 18, 19, although it will be understood that the information on each of 
these downlinks is identical. In some embodiments, satellite 1 1 is also adapted to 
transmit from earth stations 35B, 35C to earth station 3 1 . 

In the embodiment shown in Fig. 1, satellites 1 0 and 1 1 communicate 
directly with each other via inter-satellite link 14. For example, to transmit from 
earth station 30 to earth station 35C, the best path may be via uplink 15, inicr- 
satellite link 14 and downlink 19. 

Earth stations 30, 3 1 and 35A-35C each include an antenna for 
communicating with one of satellites 10 and 1 1 and appropriate electronics for 
converting between a baseband electrical signal and a radio frequency signal, such 
^5 as in Ka, Ku or C band. 

Terrestrial network 20 encompasses the public switched telephone 
network (PSTN) including wireline and wireless links, the Internet and any private 
wireline and wireless terrestrial communication channels established for 
2Q communication between controllers 40 and 45. 

For brevity, only the configurations coupled to earth stations 30 and 
35A will be discussed. In practice, many earth stations communicate with many 
satellites in the manner discussed below. 

The transmitting configuration for an earth station will now be 
discussed. Earth station 30 is an example of a transmitting earth station. 

Sending customer terminal 80 is a general purpose processor, such as 
a personal computer, personal digital assistant or the like. Customer terminal 80 is 
coupled to controller 40 via an appropriate communication channel, such as a 
30 dedicated communication line, a local area network, a dial-up communication line, 
an Internet packet switched channel and so on. Sending customer terminal 80 is 
adapted to provide a screen-based interface for entering scheduling orders for data 
file pickup and delivery, to receive notices from the central system relating to the 
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scheduied pickup and delivery services, and to provide a data file for pickup. The 

o 

data file may represent various types of information, such as text, images, audio or 
video. The data files may be delivered via Internet file transfer protocol (FTP), 
transmission control protocol (TCP), user datagram protocol (UDP) and so on. 

In one embodiment, the screen-based interface is provided via access 
5 to an Internet web site. In another embodiment, additional software for practicing 
the present technique is operative in customer terminal 80 for providing the screen- 
based interface. In some embodiments, the web site or additional software is 
activated by clicking on an icon on a virtual desktop. 

Gateway 70 is a general purpose processor is coupled to controller 40 
and data storage unit 60 via data bus 42. In some embodiments, gateway 70 is 
controlled by the sending customer although it is physically at the service provider's 
premises. Gateway 70 functions to receive a data file from data storage unit 60 in 
response to an instruction from controller 40, to convert the format of the received 

15 data file to a different format in response to another instruction from controller 40, 
and to provide the retrieved data file, as selectively converted, to transmitter 50. 

In one embodiment, gateway 70 acts as a digital video broadcast 
(DVB)/ internet protocol (IP) gateway, handling the conversion from IP packets to 

2Q DVB/MPEG II packets. Standards defining these conversions include "DVB 

Specification for Data Broadcasting" (EN 301 192), '^Digital Video Broadcasting: 
Specification for Service Information in DVB systems'' (EN 300 468), "DVB 
Guidelines on Implementation and Usage of Service Information'' (ETR 211), 
''Extension for Digital Storage Media Command and Control (DSM-CC) - 

25 

hitemational Standard (IS)" (ISO/IEC 13818-6), and so on. All of these standards 
are available at www.dvb.org. 

Compliance with the DVB data broadcast standard requires an ability 
to perform Multiprotocol Encapsulation (MPE). MPE defines how communication 
30 protocols in the form of datagrams are encapsulated in DSM-CC sections that 

comply with, for example, the MPEG-II Transport Stream packet format (ISO/IEC 
13818-1). Compliance with EN 300 468 requires insertion of service information 
data for self configuration as specified by E I S 300 468 so that program information 
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allowing receivers to automaiically tune themselves to the correct parameters can be 
placed into MPEG transponder streams. 

Although use of DVB is described herein, it will be understood that 
other protocols may be used such as asynchronous transfer mode (ATM). 

Gateway 70 is adapted to output multiple program IDs 
simultaneously, so that the central system can put multiple services into a single 
uplink stream and segment bandwidth for each customer and service. Gateway 70 
supports IP unicasting, IP multicasting and broadcasting. It also supports IP static 
and dynamic routing. 

Data storage unit 60 is a magnetic, optical, transistor, magneto- 
optical or other high capacity storage medium, and is coupled to gateway 70 and 
controller 40 via data bus 42. Data storage unit 60 functions to store data files 
supplied thereto from controller 40 and to provide the stored files to gateway 70 in 
accordance with control commands from controller 40. 

Transmitter 50 is a communication device such as a modem, and is 
coupled to earth station 30, controller 40 and gateway 70. Transmitter 50 is adapted 
to receive files from gateway 70 and to provide these files to earth station 30 for 
transmission on uplink 15 to satellite 10, in accordance with instructions from 
2Q controller 40. In practice, many transmitters may be used for each satellite, 

depending on the frequencies of the uplinks and downlinks on the satellite. The 
specific transmitter details are known to those of ordinary skill in the art and are 
omitted here for brevity. 

Controller 40 is a general purpose computer programmed according 
to the present technique, and is coupled to sending customer terminal 80, gateway 
70, data storage unit 60, transmitter 50 and terrestrial network 20 via appropriate 
communication channels. Controller 40 is adapted to receive scheduling orders for 
data file pickup and delivery from customer terminal 80 and to send status notices to 
30 customer terminal 80. Controller 40 is further adapted to retrieve a data file from 
customer terminal 80 and transfer it to data storage unit 60; to instruct data storage 
unit 60 to receive and provide information; and lo instruct data storage unit to 60 
supply a data file to gateway 70. Controller 40 is additionally adapted to 
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^ communicate with controller 45 to schedule data file delivery and receive notices 
from controller 45 relating to delivered data files. When retrieving a data file from 
customer terminal 80, controller 40 serves as a firewall. 

The receiving configuration for an earth station will now be 
discussed. Earth station 35A is an example of a receiving earth station. 
5 Receiver 55 functions as a standalone DVB/IP receiver, including a 

channel interface, a demodulator, a forward error detection/correction unit and a 
DVB demultiplexer. The multiplexed DVB signal may contain multiple program 
IDs, for carrying uni cast, multicast and broadcast traffic. Receiver 55 performs 
Q program ID filtering, and router-type filtering, that is, receiver .55 only forwards 
multicast IP subnetwork traffic for destinations coupled thereto and discards the 
remainder, in accordance with Internet Group Management Protocol (IGMP). In 
other embodiments, receiver 55 operates according to a fonnat other than DVB. 

Data storage unit 65 functions in a similar manner as data storage 
> unit 60, and will not be described further for brevity. 

Client 75 is a general purpose computer coupled to receiver 55, data 
storage unit 65 and controller 45. Client 75 is the destination for a data file 
transmitted from customer teiminal 80. Client 75 is adapted to receive data files 
from data .storage unit 65. In some embodiments, client 75 receives data files 
directly from receiver 55. 

Fig. I shows client 75 and earth station 35A co-located at customer 
premises 95. In another embodiment, earth station 35A is located at service 
provider destination premises while the functionality of client 75 is split between the 
service provider destination premises and the customer destination premises. 

Controller 45 is coupled to client 75, data storage unit 65, receiver 55 
and terrestrial network 20 via appropriate communication chamiels. Controller 45 is 
adapted to receive scheduling requests for data file delivery from controller 40 via 
terrestrial network 20. to respond thereto based on facilities availability, to notify 
receiving customer terminal of a scheduled delivery, to receive confirmation from 
client 75 that a data file has been delivered thereto, and to send notices to controller 
40 confinning data file delivery. Controller 45 is further adapted to instnict 
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55 to receive a data file firom earth station 35 A that has been transmitted on 
downlink 16 from satellite 10 and convert the format of the data file, to instruct data 
storage unit 65 to receive and provide information, and to instruct client 75 to 
receive a data file from data storage unit 65. 

Fig. 2 is a flowchart illustrating data file pickup and delivery. Fig. 2 
5 shows activity occuixing at four places: "SEND CUST" - meaning sending 

customer terminal 80, ^^NET XMT^' - also referred to as the system transmitter - 
meaning earth station 30, controller 40, data storage unit 60 and gateway 70, "NET 
RCV" - also referred to as the system receiver - meaning earth station 35A. 
controller 45, receiver 55 and data storage unit 65, and "RC V CUST" meaning 
client 75. In Fig. 2, horizontal arrows indicate transmission of information between 
locations, and the vertical direction indicates time. 

It is assumed that a user has already registered with the cenu-al 
system. Fig. 3, discussed below, is an example of a screen-based interface used for 
^5 registration. 

The process of file pick up and delivery is discussed in detail below. 
As an overview, at the scheduled pickup time, the data file is sent from customer 
terminal 80 to controller 40. If necessary, other portions of the data file are sent 
20 from other customer locations to controller 40. Controller 40 stores the data file in 
data storage unit 60. When it is time for the data file to be transmitted, controller 40 
retrieves the data file from data storage unit 60 and transfers the data file to gateway 
70 that converts the file format, for example, to DVB/MPEG II format, and delivers 
the converted data file to transmitter 50. 

25 

At the receivmg side, receiver 55 receives the data file via downlink 
16, converts its format in accordance with the scheduled delivery instructions as 
applied by controller 45, and delivers the converted data file to client 75. 
Appropriate acknowledgement and reporting to controller 40 occurs through the 
30 path of the data file so tliat its progress can be readily monitored. 

At step 100, a user at sending customer terminal 80 submits a 
scheduling order for file pickup and delivery. Fig. 4, discussed below, is an 
example of a screen-based interface for creation of a scheduling order. 
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^ At step 1 02, controller 40 of the system transmitter receives the 

scheduling order. At step 104, controller 40 checks whether facilities are available 
to transmit the data file by contacting the appropriate ones of gateway 70 and 
controller 45. Together, controllers 40 and 45 schedule transmission capacity and 
storage capacity at the transmitting and receiving sides of satellite 10. Generally, 
5 storage and conversion of a data file, as needed, occurs as the transmitting side. In 
some situations, depending on facilities availability, it may be preferable to store 
and/or convert the data file at the receiving side. 

At step 103, controller 45 receives the availability check and 
determines whether it can comply with the requested data file transfer. Generally, 
the determination is positive, and at step 105, controller 45 confirms availability, 
and at step 1 07 prepares and sends a delivery notice to client 75 providing notice of 
a future data file delivery. If the determination is negative, then controller 45 replies 
with what it can accomplish, and controller 40 may send a new availability check. 
In some embodiments, a delivery notice is not sent to receiving client 75. 

At step 106, controller 40 receives a positive availability reply from 
controller 45, enqueues the file pickup and delivery order, and, at step 108, prepares 
and sends an order confirmation notice to customer terminal 80. At step 110, 
customer terminal 80 receives the confirmation notice. 

In some embodiments, customer terminal 80 is coupled to controller 
40 via an Internet connection, and the confirmation notice is received while the user 
is still at the web site in communication with controller 40. In one case, controller 
40 is also operative as a web server. In another case, controller 40 is contacted by 
one or more web servers and provides hypertext transfer protocol (HTTP) responses 
to the web server. In a fiirther case, the confirmation notice is sent as an electronic 
mail (e-mail) message to an e-mail account specified during registration. 

In other embodiments, customer terminal 80 is coupled to controller 
40 via a circuit switched connection, and the confirmation notice is received while 
the user is still at controller 40, or is sent to an e-mail account specified during 
registration. 

When it is time for the file to be picked up, at step 120, controller 40 
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obtains the data file from customer terminal 80 via an appropriale communication 
channel such as the Internet. At step 122, customer terminal 80 receives the file 
pickup request, and at step 124, provides the requested file. At step 126, controller 
40 receives the retrieved data file and stores the retrieved file in data storage unit 60. 

In some embodiments, instead of picking up the file electronically, 
the user, also referred to as the customer, may send the file to controller 40 on a disk 
or other portable media in advance of the scheduled pickup time. In some cases, the 
data file to be picked up is at a customer location (not shown) other than customer 
terminal 80, such as at a transmitting video camera. In cases where portions of the 
data file are obtained from different locations, a different pick up method may be 
used at each location. 

In some embodiments, the customer can schedule a file pickup, and 
then schedule delivery of the file at a later time such as after the file has been picked 
up. 

At step 130, controller 40 instructs gateway 70 to convert the format 
of the stored data file, as needed, such as by separating it into datagram sized 
packets, separating it into multicast formatted packets or converting a file into a 
DVB/MPEG format file. Format conversion may be required to comply with the 
pickup and delivery instructions. Format conversion may be required by internal 
service provider transmission format requirements. Other formal conversions will 
be apparent to those of ordinar>' skill. 

At step 132, conu-oller 40 instructs transmitter 50 to transmit the data 
file, as converted, on uplink 15 to satellite 10. The transmission time is selected in 
view of facility availability, as scheduled at steps 103-106, and can be substantially 
before the scheduled data file delivery time. That is, file buffering can be performed 
in tlie transmit side or the receive side due to the presence of data storage units 60 
and 65. When data storage unit 65 is used as a temporal file buffer, it is akin to a 
cache. 

At step 133, receiver 55 receives the transmitted data file. In 
response to instructions from controller 45, at step 1 35, receiver 55 converts the 
format of the data file and stores the data file in data storage unit 65. 
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^ When it is time for the file to be delivered, at step 137, server 45 

instructs data storage unit 65 to provide the data file to client 75. At the completion 
of the file delivery, client 75 provides a delivery confirmation notice to controller 
45. 

At step 141, controller 45 provides a delivery confirmation notice to 
5 controller 40. In one embodiment, the delivery confirmation notice is sent via 

terrestrial network 20. In another embodiment, the delivery confirmation notice is 
sent via a second uplink (not shown) from earth station 35A to satellite 10 and then 
on a second downlink (not shown) to earth station 30. 
1 0 ' "^2, controller 40 forwards the deli ver>' confirmation notice 

to customer terminal 80, such as by e-mail or facsimile transmission. At step 144, 
customer terminal 80 receives the delivery confirmation notice. At step 146, 
controller 40 records the successful file delivery in a log for management and 
accounting purposes. 

In some embodiments, controller 40 also logs the progress of the file 
through the central system at other points so that a user can check the location and 
status of the file using, for example, a screen-based interface (not shown). 

In some embodiments, client 75 employs a screen-based interface, 
provided in a similar manner as the screen-based interface of sending customer 
tenninal 80. that enables client 75 to request inclusion in a multicast group from 
controller 40 via controller 45 and terrestrial network 20 or other suitable 
communications channel. 

Fig. 3 is a chart showing registration screen 1 50 for customer 
regi.stration. This screen is provided to terminal 80, for example, when terminal 80 
is in communication with an Internet web site, or has otherwise established a 
connection with controller 40. In some embodiments, a separate registration 
processor is used instead of controller 40. 

Registration screen 150 contains fields for entry of the customer's 
account name, password, e-mail address, billing infoimation and default file pickup 
and deliver)' instructions. Billing inforaiation includes a physical address and 
payment means, such as a credit card or authorized credit account. The chart in Fig. 
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3 is merely an illustrative example of registration screen 150; other designs and 

fields will be apparent to those of ordinary skill in the art. 

Some customers may wish to schedule a regular file pickup and 
delivery, for example, a daily corporate news broadcast. Registration screen 1 50 
allows the customer to specify the file pickup place or places, such as a directory on 
customer terminal 80. the format and size of the file to be picked up, the time of 
pick up, the frequency of pick up and the priority of the pick up. For example, a 
news video file has real-time priority, while low priority may be appropriate for a 
financial log or historical video file. The frequency may be daily, once a week, 
once a hour and so on. 

Customers who do not wish to have a regular file pickup and delivery 
simply omit default shipping instructions. 

Fig. 4 is a chart showing scheduling oider screen 1 70 for scheduling 
data file pickup and delivery, either on a recurring basis or as a one-time event. 
Scheduling order screen 1 70 includes data entry fields for the customer's account 
name and password, for specification of payment information if other than the 
default payment method specified at registration is to be used, for identifying the 
characteristics of the data file to be picked up, and its pickup time and frequency, 
and for identifying the destination(s) of the data file. The chart in Fig. 4 is merely 
an illustrative example of scheduling order screen 1 70; other designs and fields will 
be apparent to those of ordinary skill in the art. 

As mentioned above, in some embodiments, within a short time afier 
clicking on submit button 171, a user may get a scheduling confirmation for the data 
file pickup. In other embodiments, the scheduling confirmation is e-mailed to the 
user. 

Screens (not shown) are also provided for checking on the status of a 
scheduled data file pickup, and for modifying a scheduled data file pickup. 

The scrccn-bascd interface described herein allows a user to manage 
pick up and delivery of their files without concern for managing the communication 
facilities that actually transmit and receive the data files. Accordingly, the user's 
network management burden is reduced. 
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The present technique has been described with reference to a screen- 
based interface. In a modification, the user device may be based on audible 
presentation of information instead of visual, such as a telephone or terminal 
providing voice synthesis. 

The system of Fig. 1 is useful for multicasting, distributed hosting 
5 and network caching. 

Multicasting is a session layer protocol buih on top of User 
Datagram Protocol (UDP). It uses Class D address space, from 224.0.0.0 through 
239.255.255.255, to send data from one host to muhiple hosts. A receive host sends 
^ an IGMP join message to routers* or equivalent devices, so that the routers will 
forward the traffic to the receiving host. Multicast software for delivering content 
reliably in a satellite environment includes OMNICAST (TM) available from 
StarBurst Conununicalions in Concord, MA, and FA2ZT (TM), available from 
KenCast Software in Stamford, CT, Additional information on these products is 
' available at www.siarburstcom.com and www.lcencast.coni. OMNICAST uses a 
StarBurst proprietary Multicast File Transfer Protocol (MFTP) to deliver files to 
multiple locations. 

Distributed hosting refers to storing content from a web site at 
2Q multiple sites so that the content is closer to a requesting end user, and thus can be 
delivered faster. The system receivers of Fig. 1 are appropriate for supporting 
distributed hosting. 

Network caching refers to a configuration wherein data is stored in 

caches at various locations, and provided directly from these locations, thereby 
25 . . . 

eliminating the need to go back to a central source. Network caching conserves 
network bandwidth and reduces the processing load on the cenu-al host. More 
recent Internet applications are employing cache processing, wherein the cache 
performs functions based on the content stored therein, such as "playing" streaming 
30 video from the cache, providing billing information for pay per view content, 

modifying file identifiers for ad insertion, and sending run-time commands to a user 
for streaming software. The system receivers of Fig. 1 arc appropriate for 
supporting distributed hosting. 
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^ The system of Fig. 1 allows a user to create new files, update existing 

files or delete files at a master site, and have these changes automatically reflected 
at updates to a set of child sites. Controllers 40 and 45 cooperate to provide version 
control and backup at all sites, automatic restoration of damaged files, priority 
updating, tailoring data at remote sites, support of multiple operating systems and 
5 hardware configurations and remote verification. 

Although the present technique has been described with regard to 
data files, one of ordinary skill in the art will appreciate that the system 
configuration may also be used for streaming video with suitable modifications to 
the software described above. 

Streaming video refers to separating a video signal into packets 
which are then sent over the Internet, for example, and reassembled and displayed at 
the destination in real time. Protocols relevant to streaming video include the 
Internet Engineering Task Force (IETF) Real Time Transfer Protocol (RTP) 
15 (available as Request for Comments (RFC) 1 889), Real Time ConU-ol Protocol 
(RTCP) (available as RFC 1 890) and Real Time Streaming Protocol (RTSP) 
(available as RFC 2326). All RFCs are available at www.ietf org. 

Although an illustrative embodiment of the present invention, and 
20 various modifications thereof, have been described in detail herein with reference to 
the accompanying drawings, it is to be understood that the invention is not limited 
to this precise embodiment and the described modifications, and that various 
changes and further modifications may be effected therein by one skilled in the art 
without departing from the scope or spirit of the invention as defined in the 
appended claims. 
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What is claimed is: 

1 . A method for file transfer, comprising: 
transmitting a file using a satellite communications link in 

accordance with a scheduling order specifying pickup and delivery instructions for 
the file. 

2. The method of claim 1, further comprising confirming that 
the file has been transmitted to a provider of the file. 

3. The method of claim 1 , wherein the transmitting is 
simultaneously performed to selected destinations that are part of a predefined 
group excluding some destinations in a geographic area. 

4. The method of claim 1, further comprising receiving the 
scheduling order from a usen the scheduling order also specifying at least one 
location and time for retrieval of the file. 

5. The method of claim 4, further comprising checking facility 
availability in response to receiving the scheduling order. 

6. The method of claim 5, further comprising sending a 
confirmation notice to the user after checking facility availability. 

7. The method of claim 1 , further comprising sending a delivery 
2Q notice to a destination for the file before transmitting the file. 

8. The method of claim 7, wherein the delivery notice is sent at 
approximately the time that the scheduling order is received. 

9. The method of claim 1 , further comprising converting the 
format of the file. 

25 

1 0. The method of claim 1 , further comprising storing the file for 
a predetermined amount of time. 

11. A system for file transfer, comprising: 

a transmitter for transmitting a file using a satellite 
30 communications link in accordance with a scheduling order specifying pickup and 
delivery instructions for the file. 

1 2. The system of claim 1 1 , further comprising means for 
confirming that the file has been transmitted to a provider of the file. 



35 



wo 01/41400 





PCT/USOO/23577 



- 16- 



1 3. The system of claim 1 1 , wherein the transmitting is 
simultaneously performed to selected destinations that are part of a predefined 
group excluding some destinations in a geographic area. 

1 4. The system of claim 1 1 , further comprising a processor for 
receiving the scheduling order from a user, the scheduling order also specifying at 
least one location and lime for retrieval of the file. 

15. The system of claim 1 4, wherein the processor is also for 
checking facility availability in response to receiving the scheduling order. 

16. The system of claim 15, wherein the processor is also for 
sending a confirmation notice to the user after checking facility availability. 

17. The system of claim 1 1 , further comprising means for 
sending a delivery notice lo a destination for the file before transmitting the file. 

18. The system of claim 1 7, wherein the delivery notice is sent at 
approximately the time that the scheduling order is received. 

1 9. The system of claim 1 1 , further comprising a processor for 
converting the format of the file. 

20. The system of claim 1 1 , further comprising a data storage for 
storing the file for a predetermined amount of time. 

21 . A user interface for scheduling a file transfer, comprising: 

a terminal for displaying a data screen to the a user, tlie data 
screen including fields for specifying a file location, size, pickup time and delivery 
time, and 

means for sending information entered through the data 
screen to a central system. 

22. A method for file reception, comprising: 

receiving a file that has been transmitted using a satellite 
communications link in accordance with a scheduling order specifying pickup and 
delivery instructions for the file. 

23. The metliod of claim 22, further comprising confirming that 
the file has been received to a provider of the file. 

24. The method of claim 22, wherein the file has been transmitted 
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by multicasting. 

25. The method of claim 22, further comprising confinning 
availability of delivery according to the scheduling order, and wherein the 
confirming of availability occurs before the receiving of the file. 

26. A system for file reception, comprising: 

a receiver for receiving a file that has been transmitted using 
a satellite communications link in accordance with a scheduling order specifying 
pickup and delivery instructions for the file. 

27. The system of claim 26, further comprising means for 
confirming that the file has been received to a provider of the file. 

28 . The system of claim 26, wherein the file has been transmitted 
by multicasting. 

29. The system of claim 26, further comprising means for 
confinning availability for delivery according to the scheduling oitler. 
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